Technical annex Tilli × EEF · EdTech Implementation Companion · July 2026

How the backend serves the two user journeys: and how PII never reaches the model

This annex accompanies the UI mockup. It shows the shared system architecture, how each of the two demonstrated journeys flows through it, and the privacy pipeline that detects and removes personal data an educator might share.

1 · System architecture

One pipeline, four journeys, zero product database

Presentation
Craft CMS plugin
Native module in the EEF website. Journey UI, stage tracker, plan editor. No separate domain, login or cookies beyond EEF's own.
→
Safety boundary
PII redaction gateway
Every user input passes through detection + redaction before orchestration or any model call. Detailed in §3.
→
Orchestration
Journey controller
Deterministic state machine over Explore → Prepare → Deliver → Sustain. The application decides the next step: never the model.
Retrieval
EEF evidence base (RAG)
EEF publications chunked with implementation-stage, mechanism and evidence-strength metadata. Gemini embeddings (768-dim) in pgvector. Content updates via a documented pipeline: no code changes.
→
Generation
Gemini 2.5 Flash
Answers only from retrieved EEF passages; structured prompts per journey step; temperature-0 classification routes each question. Same model family running in Tilli production today.
→
Verification
Response checker + plan builder
Each response checked against its retrieved sources (claim ↔ citation match, hedging on mixed/limited evidence) before display. Accepted content accrues into the structured plan / survey / deck.
What is deliberately absent: no EdTech product database (so no recommendations are possible), no pupil-level data store, no accounts holding conversation history against a named individual. Session state lives in an anonymous session; the plan is the user's export.
2 · Journey execution

How the two demonstrated journeys run through the pipeline

Use case 1 · school leader
Reviewing an existing investment
1Intake → journey controller selects the "review" state machine; classifier (temperature 0) tags the problem as maths attainment, KS2.
2Free-text answers pass the PII gateway. "Mrs Hartley runs the Y4 sessions" → "[STAFF-1] runs the Y4 sessions" before the model sees it.
3Retrieval scoped to Explore + individualised instruction / digital tutoring: Toolkit strand, EdTech Evidence Review §5, DIY Evaluation Guide. Evidence-strength metadata drives the strong/mixed/limited labels.
4Assessment-plan module renders the school's aggregate figures client-side; only cohort-level numbers (never pupil rows) are accepted by the schema. Chart reading is generated against DIY Evaluation Guide passages, so limits of before/after designs are stated.
5Survey generator fills reviewed question templates per audience (parent / staff / pupil), reading-age checked; exports to print or Forms. Responses never return to the tool.
6Plan builder → outputs. The accrued structured plan renders as document (PDF/Word) or SLT briefing deck (PPTX) from the same source of truth: citations and uncertainty labels carry over mechanically.
Use case 3 · classroom practitioner
Exploring GenAI without a specific idea
1Intake → "explore AI" state machine. Because no problem is stated, the controller runs a narrowing sequence first: the model cannot skip to suggestions.
2PII gateway on every turn. If the teacher pastes a pupil's paragraph as an example, names and identifying details are stripped and flagged back to the teacher as a teachable moment.
3Dual retrieval: pedagogy corpus (Teacher Feedback guidance, Improving Literacy KS2) and emerging-tech corpus (EdTech Evidence Review). Different evidence-strength metadata keeps the two visibly distinct in the response.
4Verification enforces hedging: claims mapped to limited-evidence sources must carry uncertainty language, or the response is regenerated. A "non-tech alternative" slot is mandatory in this journey's plan schema.
5Trial-plan builder outputs a bounded pilot: scope, success measures, stop conditions, fallback: plus the data-hygiene checklist injected from EEF/DfE guidance, not generated freely.
3 · Privacy & PII pipeline

Detect, redact, disclose: before any model call

Educators will occasionally share more than they intend: a pupil's name in an anecdote, a colleague's email, a pasted mark sheet. The gateway assumes this will happen and makes it harmless. This mirrors the UNICEF-vetted compliance processes we run in AskTilli production.

1 · Detect
Layered detection: deterministic patterns (emails, phones, postcodes, UPN/ULN formats) + NER for names of people and schools + a temperature-0 LLM pass for contextual identifiers ("the only Polish-speaking boy in Y4"). Runs in-region; nothing leaves the boundary yet.
→
2 · Redact
Detected spans replaced with typed placeholders: [PUPIL-1], [STAFF-1], [SCHOOL], [EMAIL]: preserving meaning for the conversation while removing identity. Consistent within a session so the dialogue stays coherent.
→
3 · Disclose
The user sees what was removed: "We removed 1 pupil name before processing." Transparency doubles as data-protection education: especially in the GenAI journey, where safe habits are part of the outcome.
→
4 · Only then: model
The redacted text is what reaches retrieval and Gemini. Raw input is never logged, never embedded, never used for training. Placeholders are re-substituted client-side only where the user's own plan needs them.
Worked example: from the use case 1 conversation
Educator types
"Jayden M in 4B has barely used it: his mum (07700 900123) says the login never works at home."
Model receives
"[PUPIL-1] in [CLASS] has barely used it: their parent ([PHONE]) says the login never works at home."
The pedagogical signal: a home-access barrier: survives intact and feeds the equity watchpoints in the plan. The identity does not.
UK GDPR posture
Data minimisation by architecture: no accounts, no pupil records, anonymous sessions, UK/EU data residency, DPIA delivered at mobilisation and maintained per release.
Retention
Session state expires after the session ends; the exported plan belongs to the school. Redaction-event counts (not contents) are retained as an aggregate safety metric for the EEF.
Assurance
Red-team suite of adversarial PII inputs runs on every release; recall on the suite reported to the EEF alongside the accuracy rubric (proposal, Schedule B).
Tilli × EEF · technical annex to the UI mockup · indicative architecture for tender evaluation
← Back to the UI mockup